home *** CD-ROM | disk | FTP | other *** search
- I've thought about this business of getting a WWW browser to execute
- a program and I've convinced that a new URL scheme is necessary
- for some uses. In particular, you need it if you want to repeatedly
- run a program which outputs HTML (or MIME) and generally acts like
- a server.
-
- An executable MIME content type is good for "one-shot" executions
- (like a "mail developers" link which runs a mailer), but it can't
- cover the more dynamic semi-server case. Why? Because you need
- a MIME document to back up each URL your server outputs that
- refers back to the server. This is fine with an HTTP server, but
- for a browser-executed server it means having a file for every
- link which defeats the purpose.
-
- A hack to the file: scheme is mostly OK except that it limits executable
- things to file: (no big deal with the MIME executable content type),
- is not particularly abstract (it points to a specific file) and leaves
- the relative URL semantics hanging. Look at the HTML output of
- file:/bin/rn.html%/comp/sources/misc. If it outputs the anchor
- <A HREF=/comp/binaries/mac>mac</A>, does that mean
- file:/comp/binaries/mac or file:/bin/rn.html%/comp/sources/mac?
- The writer of "rn.html" would certainly prefer the latter over
- having to constantly spit out full references, but the former is
- what should really happen. Sure, we could pass in the full URL
- to rn.html so it knows the path, but that seems pretty messy.
-
- So how about this: an "exec:" scheme that looks like:
-
- exec://encoded-URL/opaque/stuff/like/other/URLs
-
- Semantics: decode the "encoded-URL", grab it and execute it
- with the rest of the URL. I used the "//" notation so
- that executables can ouput "/" rooted URLs without having
- to know who they are, that is, rn.html can say "<A HREF=/comp/risks>".
- We can do the "encoded-URL" any way we like, but suppose that
- : -> ; and / -> \. A full exec: URL might look like:
-
- exec://file;\bin\rn.html/comp/sources/misc
-
- However, with the MIME executable content type, I'd expect that
- most exec: URLs would point to files, so file: would be the default.
- Additionally, the browser might have some notion of a PATH for
- exec: files (possibly as a first-level security mechanism), so the
- whole thing could be shortened to:
-
- exec://rn.html/comp/sources/misc
-
- I fully realize that these URLs probably won't work between different
- sites. I don't expect WWW servers to be sending you these any time
- soon (unless they're trying to delete all your files :-), but
- it's possible if some general agreement on the symbolic names
- happens. For instance, it may become agreed that
- <A HREF=exec://mailer/mosaic-guys@ncsa>bug report</A> will
- fire up some kind of mail program.
-
- While the file: with %/ hack is workable, I think this is better.
- What do you think?
-
-